REMARKS 

In response to the above-noted Office Action, Applicant has added claims 8-13 which 
generally correspond to claims 1 and 3-7 respectively. Reconsideration and withdrawal of the 
rejection of record is considered in view of such amendments and the following discussion. 

Regarding the continued rejection of claim 1 under USC 102(b) as being anticipated by 
DeKoning et al., in Action, the Examiner notes that applicant has presented an argument directed to 
a feature, i.e., the XOR engine receives data directly from the host network interface via a 
transceiver) not recited in the claims. The Examiner notes that while the claims are interpreted in 
light of the speciation, limitations from the specification are not read into the claims. 

In response, while it is true that Applicant underlined the word "directly" in the argument 
presented at page 2 in the prior response, such argument was made to emphasize the structural 
arrangement which already exists in claim 1. In particular, claim 1, element b) reads: 

"a host network interface coupled to said XOR engine and for coupling to a host computer 
system." 

While it may be true that, at least theoretically, an element could exist between the host 
network interface and the XOR engine and still read on the claim, such a reading would not be a 
proper claim interpretation in light of the specification. For example, figure 1 shows the prior art 
wherein the XOR engine is connected to the host/network interface through a central cache 
memory. Figure 2 is similar. Contrast the figures. 1 and 2 arrangement with figure 3 wherein the 
XOR engine is shown to be on the host side of the central cache with no memory or controller or 
any other element between the XOR engine 33 and the host/network interface 31. As stated at page 
5 of the specification at paragraph [0029], "the XOR engine 33 resides between the host/network 
interface 31 and the central cache memory 35." This is to be contrasted with XOR engine 62 
shown in figure 2 of DeKoning where an RPA memory controller 60 is interposed between the 
XOR engine and the host interface 16. 
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Furthermore, Applicant notes that this XOR placement is not a mere design expediency. 
As explained by Applicant in the specification at pages 5-7, the XOR engine can calculate, check 
and correct parity errors in real time during data transfer. As explained in Applicant's prior 
response, memory controller 16 and DeKoning et al. is not a passive device between the XOR 
engine and the host network interface but is a required element the result of which is that while data 
from XOR engine 62 can flow to and from the host interface through memory controller 60, XOR 
62 as taught by DeKoning et al. is not coupled to the host interface as disclosed and claimed by 
Applicant. 

In this connection, it would be readily apparent to a person skilled in the art that the 
presence of memory controller 60 would preclude the XOR engine from being able to calculate, 
check and correct parity errors in real time during data transfers. 

Regarding the continued rejection of claims 2-7 under 35 USC 103 as being unpatentable 
over DeKoning et al. in view of Neufled, Applicant notes that these claims are patentable over the 
cited references since Neufled does not teach or suggest a host network interface coupled to the 
XOR engine as disclosed and claimed by Applicant. In response to the arguments at page 4 of the 
Action, the Examiner appears to be contending that trap logic 300 corresponds to the logic means 
which Applicant stated does not exist in Applicants prior response. However, as stated in 
Applicant's prior response, and as defined in Applicant's claim 2, the claimed logic means is for 
generating an XOR parity byte, checking XOR parity and correcting detected parity errors. That 
is, Applicant's logic means recites a particular and specific function which it performs. While trap 
logic 300 is, broadly speaking, logic means, as stated in column 8, its function is to trap 
addressing control signals issued by processor 20 and a memory read cycle, compare the memory 
access with range protection addresses and permit the processor to participate in arbitration for the 
host bus during the memory access. That is, trap logic 300 has absolutely nothing to do with 
checking, detecting or correcting parity errors. Accordingly, reconsideration and withdrawal of the 
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rejection of claims 2-7 under 35 USC 103 as being over the combination of DeKoning et al. in 
view of Neufled. 

Submitted herewith are new claims 8-13 where claim 8 is similar to claims 1 and 2 and 
claims 9-13 are similar to claims 3-7 respectively. The main difference is that in the added claims, 
it is expressly set forth that the generation, checking and correction of XOR parity is performed in 
real time. For this reason, in addition to the arguments presented above relating to the patentability 

of claims 1-7 over the prior art of record, Applicant submits that new claims 8-13 are further 
distinguishable over the prior art in view of the express limitation added concerning real time 
generation, detection and correction concerning XOR parity. 
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